The Formal Design Model of a Lift Dispatching System (LDS)

A Lift Dispatching System (LDS) is a typical real-time system that is highly complicated in design and implementation. This article presents the formal design, specification, and modeling of the LDS system using a denotational mathematics known as Real-Time Process Algebra (RTPA). The conceptual model of the LDS system is introduced as the initial requirements for the system. The architectural model of the LDS system is created using RTPA architectural modeling methodologies and refined by a set of Unified Data Models (UDMs). The static behaviors of the LDS system are specified and refined by a set of Unified Process Models (UPMs) for the lift dispatching and serving processes. The dynamic behaviors of the LDS system are specified and refined by process priority allocation and process deployment models. Based on the formal design models of the LDS system, code can be automatically generated using the RTPA Code Generator (RTPA-CG), or be seamlessly transferred into programs by programmers. The formal models of LDS may not only serve as a formal design paradigm of real-time software systems, but also a test bench of the expressive power and modeling capability of exiting formal methods in software engineering. SPEcial SEction DOI: 10.4018/jssci.2009062506 110 International Journal of Software Science and Computational Intelligence, 1(4), 109-135, October-December 2009 Copyright © 2009, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. intricate interactions with hardware devices and users, and necessary requirements for domain knowledge (Hayes, 1985; McDermid, 1991; Chenais & Weinberger, 1992; Liu, 2000; Wang, 2002, 2007; Ngolah et al., 2004). All these factors warrant an LDS system as a complex but ideal design paradigm in large-scale software system design in general and in real-time system modeling in particular. The lift scheduling problem has been studied as a real-time system in Chenais and Weinberger (1992) and Hamdi et al. (1995) to be NP-complete, because for n lifts, if there are p requests, then there would be upto np possible dispatching strategies. Further, the problem is dynamic, i.e., during executing a given dispatching plan, new requests presented inside the cabins of lifts and from the floors may often interrupt and change the current dispatching strategy. The request scheduler therefore must be able to find a suitable dispatching mechanism in order to ensure there is no request to wait for a long period before being served. There is no systematical and detailed repository and formal documentation of design knowledge and modeling prototypes of an LDS system nor a formal model of it in denotational mathematics and formal notation systems (Wang, 2008d). This article presents the formal design, specification, and modeling of the LDS system using a denotational mathematics known as Real-Time Process Algebra (RTPA) (Wang, 2002, 2003, 2007, 2008a, 2008b). RTPA introduces only 17 meta-processes and 17 process relations to describe software system architectures and behaviors with a stepwise refinement methodology (Wang, 2007, 2008a, 2008c). According to the RTPA methodology for system modeling and refinement, a software system can be specified as a set of architectural and operational components as well as their interactions. The former is modeled by Unified Data Models (UDMs, also known as the component logical model (CLM)) (Wang, 2007), which is an abstract model of the system hardware interface, an internal logic model of hardware, and/or a control structure of a system. The latter is modeled by static and dynamic processes using the Unified Process Models (UPMs) (Hoare, 1978, 1985; Bjorner & Jones, 1982; Corsetti & Ratto, 1991; Wang, 2007, 2008a; Wang & King, 2000; Wang & Ngolah, 2002). This article develops a formal design model of the LDS system in a top-down approach on the basis of the RTPA methodology. In the remainder of this article, the conceptual model of the LDS system is described as the initial requirements of the system. The architectural model of the LDS system is created based on the conceptual model using the RTPA architectural modeling methodologies and refined by a set of UDMs. Then, the static behaviors of the LDS system are specified and refined by a set of processes (UPMs). The dynamic behaviors of the LDS system are specified and refined by process priority allocation, process deployment, and process dispatching models. With the formal and rigorous models of the LDS system, code can be automatically generated by the RTPA Code Generator (RTPA-CG) (Wang, 2007), or be seamlessly transferred into program code manually. The formal models of LDS may not only serve as a formal design paradigm of real-time software systems, but also a test bench of the expressive power and modeling capability of exiting formal methods in software engineering. THE CONCEPTUAL MODEL OF THE LDS SySTEM The Lift Dispatching System (LDS) is a real-time computer controlled system for multiple lifts in a building with multiple floors. In the conceptual model of the LDS system, as given in Figure 1, there are three lifts serving six floors. The LDS system encompasses three lifts, a controller implemented by a processor, a set of control interfaces, and a set of 30 buttons. On each floor of the building, there are three buttons corresponding to each lift in both directions, except that there are only upward buttons on floor 1 and downward buttons on floor 6. On each floor there International Journal of Software Science and Computational Intelligence, 1(4), 109-135, October-December 2009 111 Copyright © 2009, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. is also an indicator of the current level of each lifts. In addition to the external equipments, the cabin of each lift consists of a bell and a set of internal buttons to control the door’s open/close and to enter the expected numbers of internal requests. Once an external button is pressed, its built-in lamp is lit up to indicate that the request is received by the system. If a button is pressed for multiple times after a request for that button has already been pended, there is no further effect. The system also automatically set the rest buttons on the same floor with the same direction as pressed. Lights of the same group of interlinked buttons will go off when a lift arrives to serve the request. A parked lift as dispatched for serving a request at a certain floor will automatically open and then close the door of its cabin within a predesigned period except it is forced to be opened or closed by internal buttons with a higher priority. The design constraints of the lift system and its dispatching algorithm can be informally described as follows: 1. The lift that responds to a request does so within minimum time and minimum energy consumption. 2. Only one lift should respond to a given request on a certain floor. 3. If there is no request pending, a lift should be parked on the current floor where it reached in its last dispatched destination. 4. The door of a lift remains closed except the conditions specified in item (5) is met. 5. The door of a lift keeps open when reached the floors where a current request has been identified or the lift is in the initial state on floor 1. 6. A lift does not stop to serve a request if it is moving in the opposite direction of the pending request in a given dispatching cycle. All design constraints and requirements for the LDS system as stated above will be rigorously specified in the formal LDS design models in the following sections, particularly the UPM of LiftDispatchingPC and LiftServingPC. Figure 1. Conceptual model of the LDS system 112 International Journal of Software Science and Computational Intelligence, 1(4), 109-135, October-December 2009 Copyright © 2009, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. The top level framework of the LDS system can be modeled by a set of architecture, static behaviors, and dynamic behaviors using RTPA (Wang, 2002, 2008a) as follows: §(LDS)  LDS§.ArchitectureST || LDS§.StaticBehaviorsPC || LDS§.DynamicBehaviorsPC (1) where || indicates that these three subsystems related in parallel, and §, ST, and PC are type suffixes of system, system structure, and process, respectively. According to the RTPA methodology for system modeling, specification, and refinement (Wang, 2008a, 2008b), the top level model of any system may be specified in a similar structure as given in Eq. 1. The following sections will extend and refine the top level framework of the LDS§ into detailed architectural models (UDMs) and behavioral models (UPMs). THE ARCHITECTURAL MODEL OF THE LDS SySTEM The architecture of a hybrid hardware/software system and/or a real-time system is a system framework that represents the overall structure, components, processes, and their interrelationships and interactions. The following subsections specify the architecture of LDS, LDS§.ArchitectureST, by a high-level architectural model based on its conceptual model as provided in Figure 1. Each of its architectural components will be refined as a UDM (also known as Component Logical Model (CLM)) (Wang, 2002a, 2007). The Architectural Framework of LDS System architectures, at the top level, specify a list of identifiers of UDMs and their relations. A UDM may be regarded as a predefined class of system hardware or internal control models, which can be inherited or implemented by corresponding UDM objects as specific instances in the succeeding architectural refinement for the system. Corresponding to the conceptual model of LDS as shown in Figure 1, the high-level specification of the architecture of LDS, LDS§.ArchitectureST, is given in Figure 2 in RTPA. LDS§. ArchitectureST encompasses parallel structures of LiftsST, ButtonsST, SysClockST, and ControllerST, as well as a set of events @EventsS and a set of statuses &StatusBL.; The controller of LDS, ControllerST, is a subsystem of internal control structures that may be further refined by a set of UDMs such as the RequestEvenRecordST, LiftStatusRecordST, LiftDispatchListST, and ServiceQueuesST, where the numbers in angel brackets indicate the configuration of how many data objects that share the same UDM. The events of LDS are predefined global control variables of the system, as given in Eq. 2, which represent an external stimulus to a system or the occurring of an internal change of status such as an action of users, an updating of the environment, and a change of the value of a control variable. Types of general events, @EventS, that may trigger a behavior in a system can be classified into operational (@eS), time (@tTM), and interrupt (@int) events, where @ is the event prefix, and S, TM, and  the type suffixes of string, time, and interrupt, respectively, i.e.: International Journal of Software Science and Computational Intelligence, 1(4), 109-135, October-December 2009 113 Copyright © 2009, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. @EventsS  @SystemInitialS | @tTM = §thh:mm:ss | @SysClock100msInt (2) A status denoted by ssBL is an abstract model of system state in Boolean type such as an operation result and an internal condition. The LDS status as a predefined global control variable is as follows: sStatusBL  (s)LiftFoundBL |s SysShutDownBL |s UpRequestQueueEmptyBL |s UpRequestQueueFullBL |s DownRequestQueueEmptyBL |s DownRequestQueueFullBL |s UpWaitingQueueEmptyBL |s UpWaitingQueueFullBL |s DownWaitingQueueEmptyBL |s DownWaitingQueueFullBL (3) A UDM is a generic structural type defined in RTPA (Wang, 2002a, 2007). Mathematically, the UDM is an n-tuple to model a system architectural component such as a hardware interface, an internal logical model, and/or a common control structure of a system. UDMs are a powerful modeling means in system architectural modeling, which can be used for unifying user defined complex data objects in system modeling, which represent the abstraction and formal representation of domain knowledge and structural information. Figure 2. The architectural framework of the LDS system 114 International Journal of Software Science and Computational Intelligence, 1(4), 109-135, October-December 2009 Copyright © 2009, IGI Global. Copying or distributing in print or electronic forms without written permission of IGI Global is prohibited. As modeled in Figure 2, the LDS system encompasses seven UDMs for modeling the system hardware interfaces and internal control structures as follows: LDS§.UDMsST  HardwareIntefaceCLMs ST || InternalControlStructures ST = ( || || ) || ( || || || ) (4) where the LiftsST, ButtonsST, and SysClockST are hardware interface UDMs, while the RequestEvenRecordST, LiftStatusRecordST, LiftDispatchListST, and ServiceQueuesST are internal control UDMs. The configuration of the UDMs in LDS is indicated by the numbers in the angle brackets in Eq. 4, where each number shows how many similar devices or internal control structures are equipped that share the same UDM schema. For example, there are 3 lifts, 30 buttons, 4 service queues, and 3 lift dispatching list in the LDS system. Each of the seven type system UDMs in LDS is designed and modeled in the following subsections in the two categories of system hardware and internal control structures. The UDM Structures of the LDS Hardware System The hardware system of LDS and their interfaces are modeled by a set of UDMs such as LiftsST, ButtonsST, and SysClockST UDMs. Each of the three system UDMs in LDS is designed and modeled in the following subsections.